NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/269

Text File | 1996-08-06 | 6.2 KB | 124 lines

Newsgroups: comp.lang.c,comp.std.c
Path: blackbush.xlink.net!slsv6bt!slsv6bt!kanze
From: [e-mail] (James Kanze US/ESC 60/3/141 #40763)
Subject: Re: Integral conversion e.t.c. (was: Re: Hungarian notation)
In-Reply-To: [e-mail]'s message of 30 Jan 1996 01:30:41 GMT
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: SEL
References: <[e-mail]> <[e-mail]>
    <[e-mail]> <[e-mail]>
    <4edqh2$[e-mail]>
    <[e-mail]>
    <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Date: 01 Feb 1996 13:49:52 GMT

In article <[e-mail]> [e-mail]
(Tanmoy Bhattacharya) writes:

|> In article <[e-mail]>
|> [e-mail] (James Kanze US/ESC 60/3/141 #40763) writes:
|> <snip>
|>    I agree, but...

|>    Try naming a global function read, and see what happens (on most
|>    compilers, anyway).  In fact, the Posix standard requires it, and

|> What should happen? It compiles perfectly and produces the expected
|> answer!

    [Example deleted...]
|> (By the way, your assertion is correct: in general few compilers are
|> completely conforming. My examples don't work if I change read to a
|> write :-)

|>    thus, you cannot be Posix compliant without encroaching upon the user
|>    name space.  (For example.  I'm sure that most other systems will have
|>    similar constraints.)

|> This is incorrect. What the compiler has to do is to ensure that posix
|> definitions are not seen unless I invoke undefined behaviour (e.g. by
|> #including a posix specific header or leaving an external symbol
|> undefined). Pretty easy to arrange usually (if the linker helps by not
|> loading from the library something that has already been satisfied,
|> for example, and no library routine calls a routine in user name
|> space: if necessary they call a routine which is, separately, wrapped
|> by a name in the user space): but old machines (like SunOS) have not
|> yet done this.

In my posting, I wasn't so much talking about what can be done if the
implementor wanted to do things correctly.  I was talking about the
difference between what the standard says can be done, and what you
can, in reality, do.  I know that the Posix people when to some care
to make sure that what they demanded *was* compatible with the C
standard.  The result is that fully conforming Posix implementations
are as rare as fully conforming C compilers:-).

|>    |> For example, assuming that the concept of a far pointer is truly
|>    |> required (It is really an exceptional circumstance which truly
|>    |> _requires_ it; a compiler should usually figure out whether a near or
|>    |> far pointer will work better: but that is a separate discussion), a
|>    |> compiler should invent a keyword in the implementation name space
|>    |> (e.g. __far) for it. It may provide a non-default switch
|>    |> /backward-compatible to allow it to recognize far as a keyword and
|>    |> treat it as a syntax error if used as a variable name.

|>    |> But I agree that discussions in comp.lang.c should also take care of
|>    |> current realities, even if those realities are fossils of an era long
|>    |> past, frozen in time only by the arrogant ignorance of a large body of
|>    |> users with a narrow view to the future.

|>    Well, I'm not sure that I'd consider Posix a fossil of an era long
|>    past, although it certainly reflects a long history.

|> As I said, almost no Posix extension requires diagnostic. It usually
|> specifies meaning for constructs undefined in C.

The Posix extensions may not require it, but most of the Posix (or
so-called Posix) implementations still have problems like the above
(user defined global function named write, or ...).

|>    I'm not sure where to draw the line.  Discussions of `read' certainly
|>    don't belong in c.l.c.  But simply telling someone that his system is
|>    broken because printf stopped working when he declared a global read
|>    is not going to help anyone, even if, strictly speaking, it is true
|>    according to the standard.

|>    I may be oversensitivized to this problem.  My usual hang-outs are the
|>    C++ groups.  Given the speed the C++ standard has evolved, there is no
|>    such thing as a conforming compiler, and most people have to get their
|>    programs working now, and not in 10 years time.  As a result, we do
|>    spend a lot of time talking about compiler idiocyncracies.

|> As far as comp.lang.c is concerned, I would say that pointing out to
|> people that their compiler is broken because it does not allow them an
|> external function called write is good enough. It tells them:
|>  1) The compiler should: they should complain to the vendor.
|>  2) The temporary fix is to not name the function write.

|> Isn't that good enough?

If there were just one compiler where this was the case, yes.  Where
in fact, it is a general problem on a large class of implementations,
I would tend to say: `avoid naming a function write, even if it works
on your implementation'.  A program which contains a user defined
global function named write may be conforming (according to the
standard), but it isn't portable (as things stand in real life).

This is, of course, in addition to your point 1.  If the compiler is
not conforming on this question, they definitly should complain to the
vendor.  If nobody complains, it is hardly likely that the vendor will
try and fix it.  (At one time, I had a small collection of just such
conforming programs, which I made a point of trying out on every new
compiler, and complaining when they didn't work:-).  I dropped it when
I started working with C++; my real applications generated enough
error reports without trying to be intentionally difficult.)
--
James Kanze         Tel.: [phone]        email: [e-mail]
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
                -- A la recherche d'une activitΘ dans une region francophone